1. Field of the Invention
The present invention relates to multiprocessing computer systems, and more particularly, to interrupt messaging within a multiprocessing computer system.
2. Description of the Related Art
Multiprocessing computer systems are characterized by having two or more processing units operating in parallel to effectively increase the throughput of the system. In a multiprocessing environment, tasks are divided into groups or "threads" that can be handled by separate processors. This is quite different from a single processor system, because the processing load is advantageously distributed among several processors, and the distributed tasks may be executed simultaneously in parallel. The operating system software may divide various portions of the program code into separately executable threads, and may also typically assign a priority level to each thread.
An important consideration with respect to a multiprocessing system is the handling and distribution of interrupts generated by various system resources. FIG. 1 shows a prior art arrangement to manage interrupts in a multiprocessing environment. In FIG. 1, three local interrupt controllers, 14A through 14C, are shown connected to their respective processors, 12A through 12C. An I/O subsystem 10 is shown as an initiator of interrupts that are directed to an I/O interrupt controller 16 through a set of interrupt lines 15. One of the devices constituting the I/O subsystem 10 may assert a respective interrupt signal on one of the interrupt lines 15. In response to that interrupt signal, the I/O interrupt controller 16 determines potential destinations for the interrupt signal and delivers that interrupt signal to one or more of the local interrupt controllers that are determined as interrupt destinations. The interrupt signal is delivered through an appropriate interrupt message that is transmitted on the dedicated interrupt bus 18. The interrupt message includes the bits to identify one or more of the interrupt destinations, and may also include an appropriate interrupt vector depending on the type of the interrupt being asserted by the I/O subsystem 10. For example, a lowest priority interrupt may generate a different interrupt message than a non-maskable interrupt.
The I/O subsystem may include an I/O device that asserts a respective interrupt signal based on the occurrence (or non-occurrence) of a particular event. As will be appreciated by those skilled in the art, interrupts are routinely generated by system resources such as keyboard devices, printers, timers etc. These devices may also comprise the I/O subsystem 10. Many systems also accommodate software interrupts whereby an interrupt may be asserted in response to software command. Additionally, in a multiprocessing computer system, one or more inter-processor interrupts may arise. In that case, the respective local interrupt controller transmits an appropriate interrupt message to one or more local interrupt controllers that are specified as potential destinations for the inter-processor interrupt.
Due to the number of different interrupts that may occur within a system, it is desirable to provide a mechanism to efficiently manage and distribute the interrupts to achieve optimal system performance and bus utilization. In the arrangement of FIG. 1, a dedicated wired-or bus is required to manage the interrupt traffic. The presence of such an additional dedicated bus may necessitate blending of the physical characteristics of the bus with the interrupt-management protocol to be implemented in the system. This, in turn, may make the interrupt-management protocol bus-dependent, thereby reducing the portability of the protocol when a different multiprocessor architecture is introduced. The wired-or architecture places a limitation on the number of local interrupt controllers a system can have, which, in turn, places a limitation on the number of processors that can be accommodated. This is due to the fact that a wired-or bus inherently suffers from signal degradation as loads are added and, in some cases, may necessitate slowing down of the bus frequency because of the bandwidth constraints.
The dedicated interrupt bus 18 is physically hooked to each interrupt controller as is depicted in FIG. 1. The width of the bus 18 may range from two to five bits. In any event, the serial nature of message transmission over the interrupt bus 18 requires many bit times to complete a single message. A "bit time" is the amount of time required to transmit one bit per line. When the interrupt bus 18 is an open drain bus, i.e. a bus connected to pull-up transistors to function as a wired-or bus, any interrupt controller--local or I/O--can pull the bus to a logic low state. This action by one interrupt controller may severely restrict a simultaneous transmission of anther interrupt message through the bus by a different interrupt controller. As the bus 18 is physically connected to each interrupt controller in the system, all interrupt controllers are able to track every message that is sent on the dedicated interrupt bus 18, thereby knowing when a message starts and when it ends. When this kind of arrangement is an integral part of the interrupt management protocol, only one interrupt message may be sent through the bus at a time. When multiple interrupt controllers try to transmit respective interrupt messages simultaneously, the wired-or nature of the bus and the bus-dependent interrupt-management protocol force the interrupt controllers to arbitrate in real time before sending the interrupt message on the bus. This may, in certain critical situations, not be desirable at all.
Bus arbitration normally takes place at the beginning of an interrupt message, thereby adding additional bit times for that particular message. Further, interrupt controllers that lose the arbitration priority must postpone their transmission of interrupt messages until the winner interrupt controller is taken care of by the system. Also, response to an interrupt message, e.g., accept, reject, retry, etc., takes place within the message itself. In fact, there is actually a bit time reserved within each interrupt message to allow destination interrupt controllers to indicate their response to the interrupt message, or even to drive a check_sum error response. In other words, the interrupt message is treated as a seamless event that is complete only when an indication of beginning of interrupt servicing is received by the interrupt controller that initiated the interrupt message on the dedicated bus 18. Thus, a different interrupt message cannot be transmitted on the dedicated bus 18 as long as there is a pending interrupt message occupying the bus bandwidth. This protocol, thus, results in less than optimal use of system resources.
Further, each interrupt controller, whether I/O or local, requires additional pins to allow its physical attachment to the dedicated bus 18. This increase in pin-count per interrupt controller is not at all balanced by a proportionate increase in performance throughput as discussed above. The existence of a dedicated interrupt bus 18, physical connection of each interrupt controller to that dedicated interrupt bus, and heavily bus-dependent nature of the interrupt management protocol create quite an inflexible multiprocessing architecture.